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the diagnostic 120 and software 122 servers, modules for reformatting the system 312 
and/or television content 310 areas, modules for scanning and verifying the integrity of 
individual files in the system 312 and/or television content 310 areas, and modules for re- 
installing appropriate program code modules firom the backup copies held in the data 
modules 320 or downloaded fi-om the diagnostic 120, software 122, or other remote 
servers. 

[0036] FIG. 4 is a flowchart illustrating the operation of the DVR 110 when 
performing error recovery according to an embodiment of the present invention. FIG. 4 
represents only one of many possible variations of the error recovery behavior and those 
of ordinary skill in the art will recognize that alternative embodiments may omit 
illustrated steps, perform the steps in different orders, and/or add additional steps not 
shown in FIG. 4. 

[0037] Liitially, the monitoring modules 3 16 are active and monitoring the state of the 
DVR 110. The monitoring modules 316 determine 412 whether to activate the recovery 
modules 318. This determination is made in response to the state of the DVR 1 10. For 
example, in one embodiment the monitoring modules 316 are activated when the DVR 
1 10 is booted (i.e., powered-up) and the monitoring modules activate the recovery 
modules 318 if the DVR's power button (not shown) is pressed for a certain amount of 
time, e.g. 10 seconds. In another embodiment, the monitoring modules 316 are always 
active while the DVR 1 10 is active. For example, in one embodiment the monitoring 
modules 316 are executed as a background process and track the operations of the other 
modules. If certain conditions are detected, such as a hard drive read/write error or a 
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software crash or lockup, the monitoring modules 316 automatically activate the recovery 
modules 318. In an additional embodiment, the DVR 110 activates the monitoring 
modules 316 in response to certain other conditions and the monitoring modules 316 then 
decide whether the activate the recovery modules 318. 

[0038] If 412 the monitoring modules 3 1 6 do not activate the recovery modules 318, 
then the DVR 110 resumes (or continues) 414 normal operation. Otherwise, the DVR 
110 preferably loads 416 and executes the recovery modules 318. The recovery modules 
318 preferably execute the set of recovery procedures described below with respect to 
FIG. 5. If 420 the recovery procedures are successful, the DVR 110 resumes 414 normal 
operation. If 420 the recovery procedures are not successful, then the DVR 1 10 is unable 
to self-recover jS:om the soft error. If the DVR is still capable of operation, one 
embodiment of the DVR 1 10 continues to operate (this condition is not shown in FIG. 4). 
If, however, the DVR 110 cannot operate normally, one embodiment halts 424 operation. 

[0039] If possible, the DVR 110 preferably displays information on the television 1 14 
indicating the DVR's status. This information can take the form of text messages 
explaining the actions being performed by the DVR 110, such as "Contacting Server," 
"Downloading Software," "Fail Safe Recovery hi Progress," or "Operation Halted Due to 
Unrecoverable Error." The DVR 1 10 can also indicate steps for a user to perform, such 
as calling a telephone service hotline or delivering the unit to a specific service center. In 
another embodiment, the DVR 1 10 controls the display of light emitting diodes (LED) 
(not shown) or another display on the DVR itself to indicate its status. For example, the 
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DVR 110 can cause the LED to blink a certain number of times to indicate an error code 
or function being performed by the DVR. 

[0040] FIG. 5 is a flow chart illustrating details of the "execute recovery procedures'' 
step 418 of FIG. 4. As with FIG. 4, FIG. 5 represents only one of many possible 
variations of the error recovery behavior and those of ordinary skill in the art will 
recognize that alternative embodiments may omit illustrated steps, perform the steps in 
different orders, and/or add additional steps not shown in FIG. 5. 

[0041] The recovery procedures preferably attempt to diagnose 5 10 the error or errors 
suffered by the DVR 1 1 0. hi one embodiment, the recovery modules 3 1 8 contain 
program logic for identifying common errors. For example, one or more of the files in 
the content 310 and/or system 312 area may be corrupt. The file system itself may also be 
corrupt. Another possible error is abnormal fi*agmentation of files in the content 3 1 0 or 
system 312 areas. Still another possible error is corruption to program modules or data in 
the system area 312 that is undetectable at run-time and then causes further errors to the 
DVR 110 when the program modules are executed. 

[0042] In one embodiment, the recovery procedures utihze the network interface 226 
to communicate with the diagnostic server 120 in an attempt to diagnose 510 the source 
of the error. For example, the recovery modules 318 may send the diagnostic server 120 
log files, core dump files, program variables, user provided data, etc. The diagnostic 
server 120 analyzes these data against known sources of error to identify the error. In one 
embodiment, the diagnostic server 120 saves information about errors reported by the 
DVRs 1 10 for later analysis. 
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